Establishing Distributed Hidden Friendship Relations

The social Web is going mobile and needs support for friendship management in a distributed manner, while privacy concerns mandate con guring the public visibility of one's friends. In this paper we leverage existing Web standards to describe a simple P2P protocol for establishing, enforcing, and revoking hidden friendship relations and report on an implementation for a mobile platform. We examine the suitability of hidden friendship links for bilateral and delegated access control and discuss how the social connotation of friendship can be preserved when concealing the friend's identity. 1 Online Friendship Relations and Privacy The use of on-line and social networking websites is growing, and social interaction through such systems is now part of the daily routine for many individuals [4]. Whilst the development of social networking on the Internet originated from the desire to allow individuals to update their friends or colleagues with new personal or professional information, social networking techniques are now being used to enhance the performance of many other Internet services. For example, friendship links have improved Internet search content indexing and ranking by using HTTP requests made by friends [9]; Tribler [11] is an overlay on top of BitTorrent [10], allowing users to establish friendship links and form groups in order to increase download speed or improve content discovery. Positive privacy of friendship relations. Once established, the friendship relation often confers additional rights or capabilities to friends, such as the ability to view personal photographs or send private messages ( rst use-case, UC1). In this context, friendship links on social networks are seen as privacy enhancing, since they restrict access to personal information. Unfortunately, the controls available to limit access to personal data or enhanced services are often quite primitive. Most sites allow users to restrict access to personal information to friends (of rst or higher degree) and some sites permit permission to be con gured at an individual level. There are only few sites which allow users to privately group individuals together and apply access control at the group level directly; 2 Sören Preibusch and Alastair R. Beresford such capabilities are required to provide more generic rôle-based access control facilities. As online social networking sites increasingly become platforms on which relationships are setup rather than merely replicated from the o ine world, networks provide trust metrics to guide the users in assessing other members' credibility. Despite its limitations, a user's friends count is used as a simple yet intuitive metric in contexts such as casual dating, business contacts, or electronic commerce (UC2). Friendship links may also be used by the information consumer for incoming ltering rather than for outgoing ltering by the information producer. The access control function of friendship is replaced by an information over ow prevention function. For instance, user agents may only process broadcasted events such as status updates that originate from known friends; Sunday shoppers may only enjoy receiving promotional o ers from stores that are on their favourites list (UC3). The gate-keeping function of friendship relations is not restricted to pairwise encounters, but can be extended to multihop authorisation based on functional properties of the links, including but not limited to transitivity: friends of friends or, more generally, friends of n degree may enjoy privileged access (UC4). Active consent of the original information holder or of the involved middlemen may be required for successful privilege propagation (UC5). Negative privacy of friendship relations. The set of attributes and identities linked with a friend's online pro le introduce a privacy-endangering facet into friendship relations. Having a friendship relation with somebody may be socially detrimental. For example, investigating journalists have a professional interest in keeping their sources secret (UC6). Executive professionals may wish to maintain secret ties with friends working at competitor companies (UC7). And teenagers may feel peer group pressure in choosing who they call friends (UC8). Pitfalls also arise within the online network itself when the number and kind of friends positively and negatively in uence one's social status (UC9). There are also potential negative consequences outside the social realm. Companies rely on the formalised nature of friendship relations to mine connections between users along which personality traits and socio-economic characteristics are assumed to propagate. A potential employer may refuse a candidate because of her friendship with others; and users may receive targeted advertisements based on preferences and interests their friends publicised on the network site. The nature of the friendship relation on social networking sites therefore requires the ability to hide friendship relations. Simply hiding all of one's friends does not solve the problem, because it denies the advantages of public friendship and ignores the symmetry of friendship relations, implying that either of the involved parties may reveal the existence of a link independently. In analysing an existing social network, the authors found that more than two thirds of users who chose to conceal friendships actually had exposed at least one of these supposedly hidden relationships [12]. Establishing Distributed Hidden Friendship Relations 3 Mobile networking. As the performance and capability of mobile phones increases, such devices increasingly host social networking applications. This movement provides richer (yet intermittent) connectivity, encourages greater levels of data entry, and allows the automated collection of sensor data, such as location information. Intermittent connectivity encourages more application state and functionality to reside on the device itself, rather than a remote server, and it is for this reason we believe that a move to decentralised social networks will occur. In the long term, mobile devices may function without any centralised facilities at all. Brief encounters amongst humans will trigger ad-hoc connectivity between devices. For instance, human mobility and opportunistic short-range networking may allow social networks to be built on top of delaytolerant networks, for which, in turn, stable human connectivity traces suggest reliable routing paths [6, 16]. Also, a decentralised scheme potentially provides better privacy guarantees, since trusting social network operators is no longer a prerequisite data are kept on the device under the control of the individual. Our contribution. The contribution of this paper is twofold. Building on previous research into the architecture of hidden friendship relations [12], we propose a simple protocol for establishing, enforcing, and revoking selectively hidden friendship relations in a P2P scenario. In addition, we describe an implementation of this protocol for mobile devices, providing details of the user interface and on the integration with the phone's existing messaging and contact management facilities. We review our protocol with regard to security and functional requirements, to resource consumption, as well as to standard compliance. Based on nine use-cases, we examine the suitability of hidden friendship links to convey privileges and we discuss how the social connotation of friendship can be preserved when concealing the friend's identity. 2 Hidden Friendship Relations Protocol Deployment scenario and protocol requirements. In a centralised scenario, hidden friendship links can easily be implemented by the central network server removing hidden friends from its response when serving a user's list of friends, based on the credentials the requesting client presents. In particular, the network operator is in a position to evaluate any credentials with regard to a strong identity since the user is typically session-authenticated. In an otherwise secure system, it is unlikely that user B could pose for A when presenting (replaying) one of A's credentials. In a distributed scenario, however, checking the credentials of the requesting user represents a server-like task, implying that continuous connectivity must be maintained, which is incompatible with the assumption of intermittent connectivity and prohibitively resource-consuming for mobile devices. One of the design challenges, which occurs when removing a central authority, becomes the lack of a strong yet simple proof of identity. A traditional 4 Sören Preibusch and Alastair R. Beresford decentralised public key infrastructure, such as GPG, or the web of trust imply a social graph in which identity can be mined to the detriment of hidden friendship. Design goals and requirements. In order to support a distributed social network, it is desirable if a user's list of friends is immutable with respect to requests being made by di erent parties. A distributed hidden friendship protocol is further expected to ful l the following design goals: (a) users should be able to selectively hide a self-chosen subset of their friends; (b) a friendship relation, whether hidden or public is symmetric; (c) users should be able to establish, to revoke, and to set the visibility of their outgoing friendship links uni-laterally, i.e. without coordination e orts; (d) a friendship is public i both friends make it public and it is hidden i both friends hide it; (e) a friend B of user A can check whether their friendship still holds by inspecting A's list of friends; (f) everybody should see public friendship links, and nobody except the involved parties should be able to infer a hidden friendship from either list of friends; (g) the establishment of a friendship relation requires the consent of both parties; (h) hidden and public friendship links are both made public, i.e. hiding a friendship link comes not from concealing its existence (no security through obscurity). It is outside the scope of the protocol to specify what leads to establishing a friendship. This preceding interaction pertains to the social sphere. Threat model. We outline the security goals and the threat model for a hidden friendship in general and its distributed deployment in particular. The fundamental notion is user A calling user B a hidden friend. This shall be manifested with an encrypted entry EAB in A's public list of friends. The entry can be accessed by any other user since the list of friends is public. However, it shall not be possible for a non-related third-party X / ∈ {A,B} to learn who B is from the entry in the list of friends. In particular, X is unable to locate the corresponding list of friends in which EBA should be listed in case the hidden friendship actually exists through symmetrically calling one another a hidden friend. The following assumptions are made with regard to a friend entry EAB: (a) EAB 6= EBA so that the symmetry of a hidden friendship is not obvious; (b) EBA 6= ECA so that two users having a common friend is not visible in the friend list; (c) a friends list entry corresponding to a hidden friendship can be told apart from a non-hidden friendship link; (d) the validity of EAB cannot be established by X, i.e. X cannot distinguish a real friends list entry from random data made up by A. It is assumed to be beyond the capabilities of an attacker to compute EBA from EAB and to infer B from EAB. Regarding the integrity of a list of friends, we assume that a user has sole control over her public list of friends and that requests to this list can be made in a secure manner. A potential attacker has the following capabilities: (a) monitoring tra c of users; (b) monitoring changes in the published lists of friends; (c) re-publishing hidden or public friendship entries found in other users' lists of friends. Establishing Distributed Hidden Friendship Relations 5 Regarding the system environment, the following assumptions are made: (a) devices that o er tool support for distributed hidden friendship links have su ciently synchronised clocks to assess lifetime expiry of documents such as friendship lists. Moreover, these devices experience periods of lost connectivity. We assume that (b) users checking for the existence of a device or a user do not immediately conclude the non-existence of a user from her non-reachability. As devices may cache friends lists, these cached versions may be outdated. No means for verifying cache expiry exists at periods of lacking connectivity, during which friendship revocation may occur. We, therefore, further assume that (c) users may rely on possibly outdated cache copies, (d) will implement safeguards such as short expiry times for critical applications, and (e) further delay the execution of critical friend lookups until connectivity is restored or cache validity has been established. Further design goals speci c to social networking applications. In addition to the design goals outlined above (p. 4), and for the purpose of sensible social networking applications, an additional property is desirable: any X can learn the number of hidden friends A claims to have by counting the entries for hidden friendship links. Such a requirement is in line with the use-cases UC2 and UC9. However, this further requirement con icts with the design assumption (d) established above that validity of one's friends list entry is undecidable for an outsider. The remedy of counting one's inbound friendship links which should equal one's outgoing friendship links under the symmetry assumption is not possible for hidden friendship links. A well-formedness requirement may be another practicable approach to tell bogus entries and valid friendship entries apart. Still, the countability goal is not be achievable by withdrawing the assumption (d) only. Any user may have several identities that she could use for establishing friendship links between seemingly di erent users. There are therefore at least two techniques to boost one's hidden friends count, each of which cannot be precluded in a fully distributed scenario where identities can be created opaquely at low cost. We conclude that X can only learn a lower bound for A's number of hidden friends from latter list of friends. The satis ability of weakened countability goals is discussed in Section 2, p. 9. Social networks also rely on friendship as an access control criterion as described in use-cases UC1 and UC4. The existence of a friendship relation is enforced when accessing a secured resource. We distinguish between two cases: rst, direct enforcement and, second, delegated enforcement. Bilateral enforcement relies on the design goals and is achieved since both parties involved in a hidden friendship can verify its continued existence in their own and the respectively other's records. A third party tests the existence of a friendship between two users by pairwise associating a friendship claim with a proof of identity. Granting access to privileged resources may not be limited to one's direct friends but also friends of friends or, more generally, friends of n degree. We discuss the compatibility of hidden friendship links with multihop friendship in Section 2, p. 9. 6 Sören Preibusch and Alastair R. Beresford Leveraging existing technologies. The implementation of a hidden friendship protocol, discussed in the next Section on p. 6, can be built on top of existing Internet and security technologies, keeping the protocol itself concise while leveraging established and developing standards. In particular, the following infrastructure for publishing personal information in a semantic format and for transmitting information in a secure and concealed manner is used as a basis: (a) the vCard format extension to represent social network membership information for a single individual, in particular the publisher of the vCard le [5]; (b) the representation of latter in semantic HTML using hCard for direct embedding into personal or other Web pages, including distributed social network pro le pages [1]; (c) the FOAF (friend-of-a-friend) standard to encode personal information and relationships in a machine-readable format; (d) FOAF+SSL, as an alternative to OpenId to allow for certi cate-bound identities and distributed authentication across multiple social networks [15]; (e) a contact list private to the user's individual, such as a phone book, Outlook contacts or a private FOAF le; (f) means for encrypting messages and for concealing messaging interaction, using remailers such as Mixminion [3]. Implementation: establishing friendships. Public and hidden friendship links are both stored as outgoing friendship links, mutually pointing to the other party (Figure 1). For public friendship links, the link references the other user by her public identi er, KA,such as a public key, a well-known personal Web page Uri, an email address or the Uri of her own list of friends. For hidden friendship links, the link references a public identi er speci c to this relationship only and not otherwise used by either of the parties. Each party may freshly generate such an identi er as a (public key, private key) pair, unique to a directed friendship link. The referenced party maintains the private key K−1 i associated with the public key Ki in the referencing party's public list of friends. Note that there is no need for sharing a secret. If secure channels are used for concealing the messages exchanged between two prospective friends, public/private keys used therein may be recycled. Enforcing friendships. Friendship relations are enforced upon execution of a privileged action. A public friendship relation between A and B is enforced by A inspecting B's list of friends for the existence of KA. B looks for KB in A's public list of friends. In addition, any third party X may also check for the existence of a public friendship relation between A and B. A hidden friendship relation between A and B is enforced by A inspecting B's list of friends for the existence of the relationship-speci c public key Ki that A once issued to B. Likewise, B looks for the relationship-key Kj she has issued to A. A third-party X is unable to check for the existence of a hidden friendship relation between A and B, since the relationship-speci c keys do not contain a reference to the issuing party. This behaviour is intentional, as detailed in use-cases UC6 and UC7. Revoking friendships. Friendship relations can be revoked unilaterally by either party removing the corresponding personor relationship-speci c public Establishing Distributed Hidden Friendship Relations 7